Several service providers, such as those providing multicast services, e.g., Video over Internet Protocol (VoIP), IP television (IPTV), etc., deliver multicast content from one or more head-end nodes (e.g., Points of Presence, or POPs) to one or more tail end nodes (e.g., several tail-end nodes per head-end node) over a point-to-multipoint (P2MP) tunnel. In one scenario, the head-end node receives the multicast traffic from a multicast network and transmits the multicast traffic onto the P2MP tunnel. Also, the tail-end node receives the tunneled traffic, and forwards the received traffic to another multicast network located at the tail-end node, for example, to reach end-user devices (client televisions, etc.). Notably, the P2MP tunnel, e.g., established using Multiprotocol Label Switching (MPLS) Traffic Engineering (TE), offers a tunnel connection through the service provider's (and others') network, which, as those skilled in the art will understand, allows for various tunnel advantages to be achieved through the network, such as bandwidth reservation, etc.
One particular benefit of a tunnel is its ability to provide “Fast Reroute” (FRR) functionality to protect against intermediate node failure along a primary tunnel. That is, an FRR backup tunnel may be established to protect one or more nodes (or links) along the primary tunnel and, in the event the node (or link) fails, the point of local repair (PLR) quickly reroutes the primary tunnel traffic onto the backup tunnel to circumvent the failed element. However, because the FRR backup tunnel generally needs to intersect the primary tunnel (i.e., the backup tunnel generally starts and ends at the primary tunnel), failure protection is generally not available to a head-end node and a tail-end node of the tunnel.
For instance, for a P2MP tunnel receiving multicast traffic, in the event that a tail-end node of the P2MP tunnel fails, then the head-end node of the P2MP tunnel is notified of the failure. In response, the head-end node recomputes its P2MP tunnel to a new set of tail-end nodes, particularly to the same set as the original P2MP tunnel, but with a replacement for the failed tail-end node. This process generally takes considerable time, and may require cumbersome configuration (e.g., manual configuration). Particularly, computing and signaling a P2MP tunnel generally requires more time than a conventional point-to-point (P2P) tunnel, and requires signaling and processing of the signals at each node of the P2MP tunnel.